disk: systemd-repart compatibility#2407
Conversation
We had a hardcoded default grain size of 1 MiB. This was based on the default grain size in `sfdisk` (2048 sectors, 512 bytes for the first LBA). Other partitioning tooling such as `systemd-repart` uses a different grain size by default leading to potential mismatches when rounding partitions or padding up or down to grain sizes. Let's allow this value to be configured through the image definitions YAML. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Some partitioning tools (`systemd-repart`) round down the usable end of the disk to the grain boundary (made configurable in the previous commit). This ensures that the *end* of the last partition on disk is grain aligned. `images` instead grows the last partition to take up all remaining size on the disk. When the footer is not aligned to sector size that means that the last partitions gets slightly larger than one would expect it to be. To figure out the size for the last partition we subtract the raw non-aligned header size (16,896 bytes) from the total disk size and then grow the last partition to that. This means that the last partition gains 3,584 bytes (with a 4096 byte grain size). Aligning the footer size to the grain size has the end result that the last partition becomes exactly the requested size. This new behavior is gated behind an `AlignFooter` flag in the partition table as it's new behavior and it would change all pre-existing partition tables. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Some partitioning tools (`systemd-repart`) use the convention that the first usable sector is the first LBA. The convention for this is sector 2048 (1 MiB). This is then rounded up to the grain size. `images` computes the start as `AlignUp(header + StartOffset)`. With the previous default grain size of 1 MiB this means that the first partition always started at 1 MiB when no `StartOffset` was provided. When the grain is configured to be smaller (4096 bytes) it instead produces sector 40 (20,480 bytes) which falls inside the reserved range `sfdisk` claims which then makes `sfdisk` reject the partition table because we don't pass `--first-lba` in the stage (and we probably don't want to either). Adding an `AbsoluteStartOffset` toggle allows us to set the offset to 1 MiB exactly; mimicking `systemd-repart`'s behavior. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
supakeen
force-pushed
the
repart-compatibility
branch
from
25c8f33 to
fedc243
Compare
|
Neat!! Before I read everything (not that it's a lot, this is surprisingly small), what would be the downside to changing our defaults to be the same as systemd-repart? Ignoring the fact that some users might rely on specific alignments (which sounds horrifying), are there are other problems or side effects? |
As far as the start of the first partition; currently we align it up to the grain size (which is by default 1 MiB and thus 2048 sectors). I would like to make the standard 'offset' 2048 (have it in a constant called If we do it that way there are in my opinion no harmful results though yes if people expect very specific alignments in the I don't think that happens, usually when people Want me to just make the above the default behavior? |
Let's talk about it after I've read through everything. Could be a follow-up. |
|
I think this is generally ok, but I think adding the bool for absolute start offset just makes things confusing. Just change it to behave as expected by other tools. |
3 participants
So; bit funky and a bit all over the place. This PR introduces 4 new options on the partition table struct. When combined together they make our partition tables identical to those created by
systemd-repartwith the caveat that partition tables that have start offsets (for example; theaarch64partition tables for Fedora) are not compatible, but that would have to come from the other side (e.g.systemd-repartwould need to support padding before the first partition).I've implemented each of these options separately behind toggles so we can decide if we want them 'by default' or not. Especially the
absolute_start_offset+start_offset: "1 MiB"feels funky. Perhaps someone has better ideas for that.We could also decide we don't want to be compatible at all and instead opt for a future approach (that I still plan to PR) which allows partitioning through
systemd-repartinstead of throughsfdisk.A partition table with:
Creates the exact same partition table as
systemd-repartwould create with the following inputs:Let's compare that to a partition table created by
imageswith the default settings; a 200 MiB ESP and a 2 GiB root:Note the difference in end sector and total sectors for the root partition.
When building that same partition table but adding all the toggles introduced in this PR we get:
Booting these disk images most importantly gets rid of the failing
systemd-repartservice saying that it can't fit the partitions inside the disk 🙂